For the workshop on technical debt, everyone has to write a position paper, give a case study, do a talk, OR do a tutorial. ("One of the above.")
That includes me.
So I have decided to write two position papers, and, maybe, show some of the process on Creative Chaos.
The first position paper will attempt to describe the systems issues in technical debt - why it happens. The second will be about communication and metrics.
Here's my first thought about the systems issues:
Some things to consider about tech debt:
1) Our educational system, for the most part, is built on one-off projects. Students build a program that inventories their CD collection. It doesn't work well - it even has some bugs - but it is good enough to demo and get a B+. I would go so far as to say that the majority of undergraduate programming assignments can get hacked out in a weekend with a lot of Pizza and Caffeine. And, if not, well, you can always turn in some absolute garbage, get a D for the project, a C for the class, and a B- overall for the semester.
This means that students never have to live with the pain of maintaining the pile of mud they write. Thus, our first exposure to programming actively rewards us for tech debt.
2) Technical people absolutely stink at communicating about tech debt. First, we get grandiose ideas about generalization and abstraction that management does not (and should not) trust. So when we whine about how we need more to "fix this right", what is management to think but that we are just creating yet another castle in the sky?
Also,
3) Technical people have more power than they realize. The easiest way to prevent a clever hack is to not make it. Sure, you might not be the "go to" guy anymore, but recognize what the go-to guy gets: The toughest projects. That, and pigeonholed into a technical career path.
Because
4) Non-Technical People don't realize what they are asking. Sure, the project manager asks if there is "anything you can do" to go faster, and has no problem with you taking "shortcuts" - but when the code falls apart in production, is he going to stand up and say "I authorized that, I knew it was risky, it was my choice." Or is he going to say "I asked him to be fast -- not irresponsible." Catch the different there?
So don't be irresponsible. See point #3.
4) For the most part, North American business is optimized to create short-term results at the expense of the long term. In other words, when you hear "Just do it quick, we'll do it right later", it is fair to ask if the company ever - *EVER* - actually does it later. If the answer is 'no', recognize that "just do it fast for now" means "just do it hackey for always."
Finally ...
5) A lot of old-school, "get everything right up front" people are going to use tech debt as a tool for insisting on Big Design Up Front. That is not my goal. I see BDUF projects creating a bunch of documentation and plans and things that need to updated. That up-dation is drag on the project - or, in other words, interest. Compared to other schools of big, heavyweight design, my approach leans toward "I could do the whole dang project before you finish your design."
One easy way to move fast is to travel light.
UPDATE:
Which leads to -
6) Just Do It. If I all the time spent whining and complaining that we need to "do it right" were thrown into just doing it - if for just a couple of weeks we gave up coffee breaks and the watercooler and spent time just plowing throught code - we could get it done.
Overall conclusion: Courage is a cardinal virtue for a reason.
Next question: How do we change the system so that courage (and doing the "right thing") is encouraged and rewarded?
----> That is my rough and sloppy 1.5th draft. If someone were to attend the workshop with just this, it would be the minimal amount of effort required. Of course, I intend to improve it.
But who cares about that. What do you think of my talking points?
Wednesday, May 21, 2008
Subscribe to:
Post Comments (Atom)
4 comments:
I think you are right in the sense that it does take courage to stand up and build systems that are maintainable and such, however if you do not have management on your side, you will be seen as a zealot who cannot or maybe will not deliver projects for deadlines.
Potentially, students should have to be responsible for a project or product throughout their formal education and have that assessed as part of the determination of whether they have earned their degree or not. This would require a shift in thinking by educators, but in the long run would expose students to the reality of the world they are about to enter once their schooling is complete
Matt,
I have to take you to task for your "Just do it" section. You keep trotting out this assumption that if we only gave up coffee breaks, we could just do it right. But (in my experience,) the issues that cause real long-term technical debt are the ones that cross people and applications.
For example, one that I see a lot is "This logic should be in a function/table driven." Sure, I can work through lunch and fix that on this app, but the real technical debt is that several apps have rolled their own. Fixing it over those several apps will require retesting all of those apps, which requires getting buy-in from other customers. This is the place where I keep seeing technical debt accumulate, and no amount of skipped coffee breaks will get me the buy-in from people who are currently uninvolved.
--Sean
Sean is exactly right--technical debt does not consist entirely or even significantly of the occasional ugly hack or quick-fix substitute for a real solution.
Much more importantly, debt accrues in the areas of aging or missing infrastructure/library code, incomplete or poorly normalized database schemas, poorly organized or one-off reference data, accumulating architectural and design mistakes (or decisions that were right at the time, but are no longer adequate), broken or outdated conceptual models, outdated technical dependencies, etc., etc.
In anything larger than a one person shop, these are most likely out of the individual programmer's span of control, and are not going to be fixed without senior management approval no matter how many coffee breaks the programmer is willing to skip--they take time, thought, coordination, consensus, and often some major horsepower.
So it seems to me that your points about 'technical people have power' and 'just do it' trivialize the real issues, and by treating technical debt as a coffee break issue play right into the fantasy that all that's really needed is a little more effort--nothing that would cost anything or slow down the current project, nothing that would justify not scheduling 100% of available effort on new features and new projects rather than the silly business of "rewriting working code" or "gilding the lily" that technical people keep obsessing about when "what we have works fine." Which may simply be true.
Similarly, I think that citing a 'short-term' perspective on the business end trivializes the hard financial prioritizations that those people do--making decisions that resemble nothing so much as medical triage in that there are never enough resources or time to do everything one might wish. While there's no doubt that obsession with 'making your numbers' on a quarterly basis is a pathology, it remains that most business people I know are perfectly willing to make long term investment decisions about infrastructure when the ROI for doing so is reasonably clear and reasonably probable.
So if 'just fix it' and 'it's their fault' are both--according to me--wrong answers, let's go back to the metaphor of technical debt and try again. I would suggest two primary areas of discussion:
1. Taxonomy. There are significant differences between a 20K second mortgage and 20K of unsecured credit card debt--including perhaps a 15% interest rate differential. Is it possible to start constructing a similar taxonomy of technical debt? Is some debt worse than others; do different types of debt--like loans with balloon payments--age much worse than others; are there specific categories of technical debt that have to be labeled as toxic--like short term paycheck loans--where the costs are so high, and the benefits so fleeting that they must simply be avoided at all costs? I think the effort to investigate categorizations and characterizations of the varieties of technical debt worth making. It's not all the same.
2. Debt avoidance. Are there specific approaches, practices, and techniques that will reliably lead into or out of debt? And perhaps as important, accurately measure debt and its cost? These are hard problems, but exactly what the business leaders actually need. Just saying 'don't ask for it now' is not a useful answer.
3. Debt management. Because it's not all the same, I think it worth asking whether the goal isn't more to come up with principles for managing technical debt than the illusion we're going to eliminate it. Financially, there are circumstances under which taking on debt--even a large amount of debt--makes a good deal of sense. And I think that technical people need to be cognizant of that and admit that technical debt may be the same; our goal should not be to rail against short-term decision making, but rather to help formulate the principles under which technical debt can be managed with both tactical and strategic impacts in mind. We need to help with the triage.
And finally, in reviewing what I've written, I find myself wandering away from the financial metaphor of debt entirely and leaning more and more on a medical approach. Should we talk about technical debt, or rather technical disease? That suggests a slightly refined list of investigatory questions:
1. Taxonomy and classification
2 Etiology (understanding causes and origins)
3 Prognosis (understanding expected progressions and outcomes), and
4. Treatment (understanding the most effective times and methods of intervention, based on knowledge of the previous three).
Thanks for listening,
bobD
Maybe you are wondering what is debt management,anyway? If you are, you are not alone. More customers than ever before are finding themselves in debt - and are finding themselves increasingly frustrated at what debt does to their money. In frustration, many customers turn to a debt management program or service that promises to get them out of debt quickly and painlessly.
_______
jackspar.
Post a Comment